The Interactive Content Paradigm
Computer application paradigms go through a constant process of evolution. Fifteen years ago, personal productivity applications typically were text-based, ran in full screen mode, and each application tended to employ a unique set of user interaction commands. As multi-windowed graphical user interface systems became popular, applications developed for these environments began to adopt standard types of interface models, to minimize users' confusion as they switched back and forth among multiple open applications. As a result of feature competition among vendors, productivity applications built for these windowed environments began to grow larger and larger. Simultaneously, users began to demand easy transfer of data between documents created with various applications. This led to the creation of compound-document architectures, such as Microsoft's Object Linking and Embedding (OLE) system. OLE-based applications were designed from a document-centric mindset, allowing several large monolithic productivity applications to share a single document view and “trade off” the graphical interface, so that the user wouldn't have to move his or her eyes away from the document being worked upon as each application was interactively activated (usually with a double click on a bitmap in the document) by the user. This model worked well enough when only a few major applications were involved, and when the user was primarily interested in editing documents which would be printed for use. The growth of the Web, however, ushered in a new use for document files—as a direct tool for networked communications and information retrieval.
The Web's new plug-in and applet technology created a new paradigm for application development. This new system focused on the document as a container for multiple small embedded program objects, rather than as the OLE-style task switcher of the Windows model. This new system also ushered in a new interaction paradigm, as well. The Web document became the primary application, with the document automatically choreographing the collection of document component data and the activation of the embedded applications necessary to present the user with a single and seamless interactive interface to the document's content.
The UCSF/Eolas WAPI
The Web-document-as-application model was first established at the University of California, San Francisco's Center for Knowledge Management. Their work, and their proposal for a standard Web API (WAPI), was described in the lead article of the February, 1996, issue of Dr. Dobb's Journal. This technology allowed the creation and use of “plug-in” applications that Web content authors could easily employ to dynamically extend the functionality of WAPI-enhanced Web browsers and Web pages at viewing time, without having to modify the actual browser code. Although WAPI did not, itself, become an industry standard, it inspired later commercial systems that went on to transform the entire computer software industry.
The Netscape Plug-In API
Essentially modeled upon the UCSF/Eolas WAPI, the Netscape browser plug-in API created a de-facto standard that has been implemented in all major browsers. This resulted in the subsequent development of hundreds of plug-ins that were then made freely available online, all of which conform to a standard architecture. The availability of such a large number of application components has made the very popular and powerful platform for application development. The Web document parsing model allows late binding of these application components, together with runtime fetching of component-specific data objects, thereby insuring that users can both always enjoy the latest improvements to component programs and always see the latest updates to embedded object data. It also allows application design to be independent of underlying computer system architecture. This has proven to be a very effective means for application integration with legacy software systems, proving very popular among corporate applications developers.
Scripting Languages
Modern scripting languages, such as Tcl/Tk, provide the ability to write text scripts which define interactive applications through run-time parsing of script files. Similar to the situation with Web pages, this type of architecture provides for late binding of application functionality through such runtime script parsing. Tcl/Tk provides a standard APIs for enhancing both the command set and widget set of the interpreter through interpreter extension that are loaded at runtime. Although this provides some advantages similar to those of browser plug-ins, there are not nearly as many widget extensions available as there are browser plug-ins. Furthermore, the interpreter extension mechanism did not make provision for late binding of component application code with application data, as the browser plug-in model does.
What is Needed
A system is needed that allows general program development systems to benefit from the large number of embeddable applications, in the form of browser plug-ins, that are available to easily expand the functionality of these development platforms at run-time, as well as to provide runtime binding of component logic with remotely-networked data objects.